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Abstract — Recent research in the domain of real-time schedul- 
ing theory has tackled the problem of scheduling mixed-criticality 
systems upon uniprocessor or multiprocessor platforms, with the 
main objective being to respect the timeliness of the most critical 
tasks, at the expense of the requirements of the less critical ones. 
In particular, the less critical tasks are carelessly discarded when 
the computation demand of (some of) the high critical tasks 
increases. This might nevertheless result in system failure, as 
these less critical tasks could be accessing data, the consistency of 
which should be preserved. In this paper, we address this problem 
and propose a method to cautiously handle task suspension. 
Furthermore, it is usually assumed that the less critical tasks 
will never be re-enabled once discarded. In this paper, we also 
address this concern by proposing an approach to re-enable the 
less critical tasks, without jeopardizing the timeliness of the high 
critical ones. The suggested approaches apply to systems having 
two or more criticality levels. 

I. Introduction 

The current trend in embedded systems is towards collocat- 
ing multiple functionalities on shared resources, as illustrated 
by industrial initiatives in both the aerospace and automotive 
industry. Nowadays, this trend is even getting stronger with 
the introduction of multiprocessor and/or multicore architec- 
tures. With such collocation however, it is unlikely that all 
functionalities share the same level of importance (criticality), 
and the timeliness of some functionalities might appear more 
important than others. In this context, mandatory certification 
of whole (or subset of) the system by statutory Certification 
Authorities (CAs) might be required to guarantee the correct 
behavior of the latter When certifying a subset of the function- 
alities, the CAs have to make assumptions about the Worst- 
Case Execution Time (WCET) of tasks. In practice, it can 
be observed that the more a task will be assumed critical, the 
more will it be certified using strongly pessimistic assumptions 
about its behavior at run-time. In this context, mixed-criticality 
(MC-) systems are an attempt to model systems that need 
to be certified using various assurance levels. The increased 
pessimism assumed for the more critical tasks during the 
certification process however introduces a significant over- 
provisioning of resources at run-time for the latter, having as 
consequence that the scheduling of mixed-criticality systems 
must simultaneously deal with two contradictory goals: 

1) On one hand, and since each task is supposed to carry out 
some useful computation for the system, it is desirable 
to respect the timeliness of all tasks, whatever their 
criticality is, which means that the over-provisioning of 



resources required during the certification of the more 
critical tasks could be untighten somehow at run-time; 
2) On the other hand, and since the higher the criticality of a 
task is, the more dramatic the consequences related to the 
failure of respecting their timeliness could be, it seems 
rather cautious to strictly respect the over-provisioning 
of resources of the more critical tasks, even if this means 
to interfere with the timeliness of the less critical ones 
(which is as meaningless as the criticality of these is low). 

In practice, these goals are not necessarily exclusive though, 
and it is possible to pursue them both, at least to some extent. 
Indeed, beyond vouching for the correctness of the whole (or 
part of) the system, the certification process also allows for 
specifying for how long the functionalities can execute concur- 
rently without interfering on each others temporal constraints. 
Indeed, when a task is certified by some CA, it is assuming a 
behavior, for the other tasks of the system, the pessimism of 
which depends on the criticality of the task(s) being certified. 
Consequently, as long as these assumptions hold at run-time, 
all the tasks that were certified up to that assurance level are 
guaranteed to meet their deadline. However, if a more critical 
task violates these assumptions, by executing longer than was 
assumed during the certification process, then the timeliness 
of the whole system can no longer be guaranteed anymore, 
which results in suspending the tasks that are less critical to 
ensure the timeliness of the tasks being more critical. In the 
state-of-the-art literature, the period during which these tasks 
are prevented from executing, henceforth called the suspension 
delay, is considered to be unlimited. 

With little thought, one can notice that mixed-criticality sys- 
tems can be seen as systems that exhibit multiple behav- 
iors, issued from several operating modes, where each of 
these operating modes is characterized by a given set of 
functionalities. Such systems are commonly referred to, in 
the real-time literature, as multi-moded systems [1]. When 
viewing mixed-criticality systems as multi-moded systems, the 
transition from one operating mode to the other reduces the set 
of tasks performed by the system. Indeed, less critical tasks 
are suspended, but new tasks are never introduced (at least 
in the traditional way of handling mixed-criticality systems, 
as we will present an approach which allows to overstep 
this restriction). The transition from one mode to the other 
is triggered when the system detects that the certifications 
assumptions does not hold anymore. 

When considering the temporal robustness of the system, 



mixed-criticality is a natural approach, since it aims at favoring 
the timehness of the functionahties that are crucial for the 
system. Nevertheless, discarding carelessly tasks that are less 
critical may have severe consequences on the system's consis- 
tency. Indeed, a task that is executing could be accessing data, 
the integrity and consistency of which has to be preserved. 
Under these assumptions, it is strongly undesirable to kill 
a job incautiously. It would therefore be wiser to allow the 
jobs released by less critical tasks to complete their execution 
when the transition from one operating mode to the other is 
triggered, but this transition stage might introduce a transient 
overload which should have no impact on the timeliness of 
high criticality tasks. Furthermore, while task suspension is 
carried out with concern for the respect of the timeliness of 
the high critical tasks, a suspended functionality can no longer 
handle the task it is in charge of. Consequently, an everlasting 
suspension delay might appear as strongly undesirable, and we 
might wish to be able to re-enable a suspended task at some 
point during the execution of the system. 

A. Related Work 

Mixed-Criticality scheduling is a research domain initially 
introduced by Vestal [2]. Nowadays, the Mixed-Criticality 
(MC)-Schedulability problem is known to arise in the con- 
text of applications being subject to multiple certification 
requirements. Many work has addressed the problem for 
systems implemented upon uniprocessor platforms [3]-[8]. 
More recently, research has been oriented towards the study of 
mixed-criticality scheduling upon multiprocessor platforms [9] 
[10]. Let us highlight that many of these work focused on a 
restricted and easier case of mixed-criticality systems, called 
dual-criticality systems, presenting only two distinct criticality 
levels. Nevertheless, to our knowledge, no work has tackled 
the problem that arises when mixed-criticality real-time tasks 
are incautiously discarded. Though in a previous work [8], we 
highlighted the fact that task suspension was often carried out 
too early, and that the system's computational resources could 
be exploited more cleverly. We also addressed the problem 
of managing task re-enablement. However, our work focused 
only uniprocessor platforms, while this work will be applied 
to the more general case of identical multiprocessor platforms. 

B. This Research 

We believe that a multi-mode approach can bring some 
insight on how the problems mentioned in Section I-A could 
be formalized. To our knowledge, mixed-criticality systems 
have never formally been defined as multi-moded systems. In 
this research, we thus seek to establish a formal link between 
mixed-criticality and multi-moded hard real-time systems upon 
identical multiprocessor platforms. We will then show how 
to safely complete the execution of jobs released by the 
less critical tasks, potentially after their deadline, when the 
computational demand of the more critical tasks in the systems 
increases. In our opinion, it is safer in terms of system integrity 
to complete a job beyond its deadline, instead of dropping 
it carelessly once the latter is reached. We will also show 



how to safely reduce the suspension delay suffered by the less 
critical tasks as the system load decreases, by allowing the 
re-enablement of the latter This problem was almost never 
tackled in the current literature, but still presents a significant 
interest, since the less critical tasks can improve the overall 
behavior of the system. Finally, since the notion of mixed- 
criticality systems initially did not put any restriction on the 
number of criticality levels, and has been implemented using 
various degrees of criticality by industrial standards', our 
approach can be applied to task sets having any number of 
criticality level. This is an attractive feature, as it is much 
more compliant with current industrial standards. 

II. Model and Definitions 

A. Mixed-criticality Specification 

We consider multiprocessor platforms composed of a 
fixed number m of identical processors, denoted by tt = 
{tti, 7r2, TTm}. Furthermore, we consider mixed-criticality 
sporadic task sets r = {ti, T2, t„}, where the maximum 
criticality of a task is bounded by a natural value which we 
denote by L. A task in such a system is characterized by a 
4-tuple of parameters {Ti, Di, Li,Ci} where: 

• Ti E Nq is the minimum inter-arrival time separating two 
consecutive activations of task r^; 

• Di E No is the deadline of task Ti, with Di <Ti, 

• Li e No is the criticality of the task Ti, with Li < L; 

• Ci e Nq is a size L vector of WCET, where C^ii) is 
an estimation of the WCET of task at criticality level 
£e [l,L]. 

Given these parameters, each task Ti will generate a potentially 
infinite sequence of jobs, each release being separated by at 
least Ti time units, and each job having a hard deadline Di 
time units after its release. We assume Ci{£) is monotonically 
increasing for increasing values of i. More precisely, for task 
Ti the following two conditions hold: 

• We a{e) < Qie + 1); 

. We [L„L], a{£) = aiL,). 
It follows that no task is supposed to execute longer than its 
WCET at its own criticality level. The /c* job Jij, released 
by a mixed-criticality task Ti is characterized by a 3 -tuple 
{riM,di^k,Ci^k} where: 

• ri^k G N is the time instant at which J^ fe was released. 
Since we consider sporadic task systems, we have ri^k — 
ri,k-i > Ti, and r^^i > 0; 

• di^k G No is the absolute deadline of Ji^k- More precisely, 

di,k = n^k + Di; 

• Ci,k G No is the exact execution time of fc. From the 
specifications of Ti, we can say that Ci^k < Ci{Li), but the 
exact value of Ci k will not be known until Ji k completes 
its execution; 

• fi,k G No is the absolute time at which Ji ^ finishes its 
execution. Again, this value will only be known once J^ fc 
actually completes its execution. 

'The RTCA-D0178B standard, for aerospace, defines 5 criticality levels, 
while the IS026262, in the automotive industry, defines 4 criticality levels. 
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Definition 1 (Available job). At any time t, we call the fc" 
job Ji^k released by task available if t > ri,k and J^jt has 
not yet completed its execution. 

The actual execution time of job J; ^ is not known from 
the specification of t^, but will only be discovered when 
Jj fc completes its execution. Besides, the behavior of task Tj 
might change from one execution to the other, so the actual 
executions times of the sequence of jobs released by may 
vary, leading to introduces the notion of task scenario. 
Definition 2 (Task scenario). We define the scenario s* of task 
Ti at time t as the set of exact execution times {ci^i, c,;,fc} 
for each of the k (k being dependent of t) jobs released by 
that already completed their execution at time t. 
Definition 3 (Task set scenario). We define the scenario of 
the mixed-criticality task set t at time t as = {s\, sj^}. 
Definition 4 (^-interval). Given a task set scenario, an £- 
interval is an interval [ta,ti,) such that at time ta, the system 
switched at criticality level £, and the criticality of the system 
remained at level £ until time tt,. 

Definition 5 (Worst-case response time). The worst-case 
response time (WCRT) Ri{£) of task Ti at criticality level 
£ is the maximum duration to execute any job of t^, in any 
scenario of criticality £. 

B. Modeling Mixed-Criticality in Terms of Multi-Mode 

In this section, we propose a formalization of sporadic 
real-time mixed-criticality tasks in terms of multi-mode tasks. 
Each such task can be seen as being composed of different 
execution modes, and can be represented by means of a tuple, 
as described below: 

where Afi, Af^ represent the different operating modes to 
which the task belongs, and X^^^ represents the value of 
parameter X of task Ti when Ti is executed in the operating 
mode Aly. Consequently, a natural representation for the 
mixed-criticality task n = {Ti,D^,Li,{Ci{l), ...,Ci{Li)}} 
is by means of the following tuple: 

r, -K = {T,;,A,C,(1)},... 

rf' ={T,;,A,C,(i,)}} 
The interpretation of the tuple is the following: when the 
system is executing in operating mode M^^ , task is executed 
according to the parameters given by t^'^ . The scheduler thus 
makes the assumption that Ti will not generate a job the 
execution time of which will exceed Ci{£i). If does release 
a job whose execution exceeds Ci{£i), then a transition from 
one operating mode to another occurs. If the system switches 
from mode M^^ to mode Me^, then t; is executed according to 
the parameters given by r^^ . From that specific time onward, 
the scheduler consequently assumes that t; will not generate 
jobs whose executions will exceed Ci{£2)- A task Ti belongs 
to every operating mode up to its own criticality level. More 
precisely, Ti E ^ £ < Li. A task Tt will be enabled 
in every operating mode to which it belongs, and will be 



suspended in every other operating mode. 

Definition 6 (Enabled/suspended task). At run-time, a task 

Ti is said to be enabled if can generate new jobs that 

are dispatched by the scheduler Otherwise, Ti is said to be 

suspended. 

In the following, we will consider that the system is running 
is mode Mg at time t if and only if all tasks of criticality less 
than £ are disabled, no job of criticality less than £ is still 
available at time t, and every task of criticality greater than 
or equal to £ is enabled. Notice that at system start-up, the 
system is running in operating mode Mi, which implies that 
every task is enabled. In the remainder of the paper, we will 
denote by = {r^^, t„^} C t the set of tasks belonging 
to operating mode M^, i.e. the set of tasks r, with Lj > £. 

C. Presentation of the MSM Scheduler 

In Section Il-A, we introduced the concept of criticality 
level of the scenario. This concept allows to define what 
is considered as being a feasible schedule when considering 
mixed-criticality systems. 

Definition 7 (Feasible schedule). A schedule for a scenario 
s* is feasible if, during every i'-interval, 1 < £ < L, every job 
Ji,k\Li > £ {1 < i < n) that completed its execution by time 
t, received execution time Ci,k between ^ and di^k- 

This definition implies that mixed-criticality scheduling is 
only concerned with respecting temporal constraints of tasks 
the criticality of which is higher than or equal to the criticality 
level of the scenario. 

Definition 8 (5-Schedulable). Let 5 be a scheduling policy, 
and T a mixed-criticality task set. We say r is 5-Schedulable 
if, for any scenario of r, S generates a feasible schedule. 

Since an on-line scheduling policy discovers the exact 
execution time of the jobs when they complete their execution, 
the criticality level of the scenario is not known beforehand. In 
the state-of-the-art way of handling mixed-criticality systems, 
as soon as a job exceeds its WCET of level £, the criticality 
of the scenario is raised to level £ + 1, all available jobs of 
criticality lower than £ + 1 are dropped, and future releases 
from tasks of which the criticality is lower than £ + 1 are no 
longer taken into consideration. At this point, recall that the 
goal of this research is to overstep these restrictions. Finally, 
the following definition specifies what is considered as being 
an MC-Schedulable system. 

Definition 9 (MC-Schedulable). A mixed-criticality task set r 
is MC-schedulable if there exists a scheduling policy S such 
that T is 5-schedulable. 

In the remainder of this paper, we consider the multi- 
processor global preemptive work-conservative static-priority 
scheduler MSM proposed by Pathan [9], with the following 
interpretation: 

• at each time instant, a global scheduler dispatches the m 
highest priority jobs (if any) on the m processors of the 
platform; 

• a preemptive scheduler reserves the right to interrupt a 
job Ji belonging to a task Ti, that is executing on a given 
processor, to assign this processor to another available 
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job Jj belonging to a task Tj, with i ^ j\ 

• a work-conservative scheduling strategy never keeps a 
processor idle when there are available jobs; 

• a static-priority scheduler assigns priorities to the tasks 
of the system, each job being scheduled inheriting from 
the priority of the task that released it. 

The algorithm MSM thus dispatches available jobs according 
to traditional global static -priority scheduling, but has two 
additional implementation features, namely job execution mon- 
itoring, in order to detect a transition to a higher critic ality 
level, and task suspension, to drop the less critical tasks when 
such a transition is detected. To our knowledge, MSM is the 
only multiprocessor scheduler that can be applied to mixed- 
criticality task sets having any number of criticality levels. 
Furthermore, and as already motivated by Pathan [9], static- 
priority schedulers are generally preferred by industries, as 
their decisions are predictable, thus enforcing the reliability 
property of the real-time systems they schedule. 
The priority ordering of a task set is constructed according to 
Audsley's Optimal Priority Assignment (OPA) approach [11], 
according to the response time analysis of the system. These 
notions are further discussed in Sections Il-Cl and II-C2. In 
the remainder of the paper, we will denote by hp(Ti) the set 
of tasks Tj having a priority higher than r^, and by Ip(ri) the 
set of tasks Tj having a priority lower than r^. 

1) The Worst-Case Response Time Computation: 
This section briefly introduces the work proposed by 
Pathan [9]. An upper-bound on the WCRT R^{tj of task n 
at criticality level £ e is computed by considering the 

execution of any job Ji k released by Ti in a window starting 
at Ji^fc's release time r^.fc, and finishing A time units later, i.e. 
at time instant ^ + A. The procedure aims at defining an 
upper-bound on the workload, the interfering workload, the 
total interfering workload, and the interference (as explained 
in the following definitions) suffered by task Ti in any scenario 
of criticality level (. during that interval. 
Definition 10 (Workload). The workload of a higher priority 
task Tj within the window of size A is the cumulative length 
of time interval during which the jobs released by Tj execute 
within the window. 

A task Tj G hp(ri) is considered as a carry -in task if Tj 
released a job before the start of the window, and that job 
executes (partially or fully) within the window. Otherwise, Tj 
is considered as a non carry-in task. Pathan [9] highlighted 
the fact that if a higher-priority task is a carry-in task, then 
its worst-case interference on the lower-priority task is higher 
than if it was non carry-in. 

Definition 11 (Carry-in/Non Carry-In Interfering Workload). 

The carry-in interfering workload lj\{/^,l) (resp. non carry- 
in interfering workload l!|"^(A,€)) of Tj on task Ti is the 
cumulative length of time interval during which a job released 
by a carry-in task Tj (resp. a non carry-in task Tj) executes, 
and Ji not dispatched on any processor. 

The difference between the carry-in and non carry-in in- 
terfering workload of a task Tj <E hp(Ti) will be denoted by 



Definition 12 (Total Interfering Workload). The total inter- 
fering workload ii(A,£) is the sum of interfering workload 
of all the higher priority tasks within the window. 

The MSM algorithm computes the total interfering workload 
of task Ti as follows: 



ir/'(A,^) (1) 

where hp„j_i is the set of at most m — 1 carry -in tasks 
belonging to hp(rj) that have the largest value of I°"^^^(A, £). 

The reason to consider at most m — 1 carry-in tasks comes 
from a discussion from Guan et al. [12], formalized in the 
following property. 

Property 1. The total interfering workload is upper-bounded 
by considering at most m — 1 carry-in tasks within the window 
of any lower priority task, when considering global static 
priority scheduling of constrained-deadline sporadic task sets. 
Definition 13 (Interference). The interference suffered by a 
task Ti in any scenario of criticality level £, and during a 
time interval of length A, is the cumulative length of time 
interval during which the m processors are busy executing 
tasks belonging to hp(ri). An upper-bound on the interference 
suffered by t^ over an interval of length is given by j . 

Finally, and from the above definitions, since in any scenario 
of criticality level £, Ji,k is allowed to execute for at most 
Ci{t} time units, the WCRT R^{£) of task at criticality 
level I is obtained by determining the least fixed point of the 
following function: 



(2) 



Since Ii(A,^) is an upper-bound on the total interfering 
workload suffered by task Ti, the actual total interfering 
workload suffered by Ti over an interval of length A, in any 
scenario of criticality level I, will be denoted by I*(A,£). 

2) Finding Priorities Using Audsley's Approach: 
The response time analysis described in Section II-Cl is used 
to find a static-priority ordering of the mixed-criticality task set 
T, as depicted by Algorithm 1 . Indeed, at each step, the method 
tries to identify a task Ti satisfying Ri{i) < Di, 1 < I < Li'. 
If such a task is found, then the same reasoning is iteratively 
applied to task set r \ {t^}. Otherwise, if for every task Ti, 
3£ I Rt{£) > Di, then the method fails. 

D. Mode Transition Specifications 

A change in the operating mode of the system is instantiated 
whenever the system detects a change in its internal state. 
More precisely, switching from criticality level £i to criticality 
level £2 can be seen as switching from one operating mode, 
referred to as the oW-mode M^^, to another operating mode, 
referred to as the new-mode M^^. A Mode Change Request 
(MCR) is defined as being the event that triggers a mode 
change transition. In the current state-of-the-art literature, the 
only MCR that is considered is triggered whenever the system 

^This is due to the fact that to our knowledge, there is no proof that Ri (£) < 
R,{e+1), 1 < e < L holds. 
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Algorithm 1: OPA Algorithm 
pr ^ \t\ 

while r 7^ do 

Let Ti be a task from t; 

if Ri {£) <D„l<£<Li then 

Assign Ti the priority pr; 

T ^ r \ {rj; 

pr pr — 1; 

else 

1^ return error; 

detects that a task exceeds its WCET at criticality level £, 
1 < £ < Li, resulting in the system to switch from operating 
mode AI( to operating mode A/^+i. In the remainder of this 
paper, this MCR will be referred to as an increasing mode 
change request denoted by IMCR£+i. 

Definition 14 (Increasing Mode Change Request). Whenever 
the system is running in operating mode M^, an increasing 
mode change request from criticality level £ to criticality level 
^ + 1, e [l,L), denoted by IMCR^+i, is the event that 
will result in switching from operating mode AIi to operating 
mode Mf+i. The time at which IMCR^+i is triggered will be 
denoted by iiMCRf+i- 

To handle this transition, the traditional approach that is 
currently implemented in the state-of-the-art literature consists 
in suspending instantaneously and forever tasks that do not 
belong to the new mode, their potential available jobs at 
time iiMCRf+i^ henceforth called the rem-jobs, not even being 
dispatched anymore. The transition stage is thus trivial, and the 
system instantaneously switches from operating mode Mg to 
operating mode Mi+i- By suspending the less critical tasks 
upon an IMCR^+i, the goal is to respect both the {£+1)- 
periodicity and (^H-l)-feasibility, defined as follows. 
Definition 15 (^-periodicity, adapted from [1]). The £- 
periodicity is the property that requires the activation pattern 
of each task t; such that Li > £ to be respected. In other 
words, the activation pattern of a task Ti should not be altered 
by increasing mode change requests up to t^'s own criticality. 
Definition 16 (^-feasibility, adapted from [1]). The £- 
feasibility is the property that requires each task Ti such that 
Li > £ to meet its deadline. 

Consequently, an increasing mode change request IMCR^+i 
y£ < Li should have no impact on the deadline of a task r^. 
With concern for the respect of these properties, the traditional 
approach mentioned above however introduces two major 
drawbacks. On one hand, and since the tasks belonging to 
the old-mode might be accessing data, it might appear more 
cautious to allow them to complete their execution before 
discarding them. This nevertheless could result in a temporary 
overload which could jeopardize the timeliness of the new- 
mode tasks. The transition should therefore be managed in 
such a way that the (£H-l)-periodicity and (i'H-l)-feasibility 
properties are preserved, while the rem-jobs could be allowed 
to complete their execution. Furthermore, as an everlasting 
suspension might not be necessary to keep on respecting the 



(^H-l)-periodicity and (^H-l)-feasibility, we would also like to 
re-enable the less critical tasks as soon as possible. Achieving 
the second goal nevertheless calls for the use of a new mode 
change request, namely a decreasing mode change request. 
Definition 17 (Decreasing Mode Change Request). Whenever 
the system is running in operating mode M^, a decreasing 
mode change request from criticality level h to £, \l£ e [1, h), 
denoted by DMCR^, is the event that will result in switching 
from operating mode A//, to operating mode Mg. The time at 
which DMCRf is triggered will be denoted by toMCRj- 

We again insist on the fact that current research in the 
field of mixed-criticality never considers the re-enablement of 
previously suspended tasks, at the exception of [8]. Based on 
the two mode change requests that are considered, we present 
in Section III mode change protocols whose goals are: 

• Upon an IMCR^+i, complete the execution of the rem- 
jobs as soon as possible, as this will improve system 
consistency; 

• Upon a DMCRf, re-enable the previously suspended tasks 
belonging to mode Mg as soon as possible, as this will 
improve the system's overall behavior. 

Definition 18 (Valid increasing transition protocol). Assuming 
the system is running in operating mode Mg, an increasing 
transition protocol V is said to be valid if and only if, upon 
an IMCRf+i, V ensures both the (^+l)-periodicity and (^+1)- 
feasibility. 

Definition 19 (Valid decreasing transition protocol). Assum- 
ing the system is running in operating mode M/j, a decreasing 
mode transition protocol V is said to be valid if and only 
if, upon an DMCR^, V ensures both the /i-periodicity and h- 
feasibility. 

It follows that the traditional approach is a valid increasing 
transition protocol, since upon a IMCR^+i, and from time 
^iMCRf+i onward, it aims only at respecting the timeliness 
of tasks the criticality of which is at least equal to £ + 1. 
Furthermore, the former approach does not consider 
decreasing mode change requests, so the timeliness of the 
high critical tasks can not be jeopardized by the re-enablement 
of the less critical tasks. By extending this approach to allow 
the rem-jobs to complete their execution, and allow the 
re-enablement of the less critical tasks, we thus only seek 
to achieve a cleverer usage of the platform on which the 
mixed-criticality system is executed, without compromising 
the reliability of the considered mixed-criticality system. In 
the literature related to multi-moded systems, it is sometimes 
assumed that a mode change request IMCR^+i may only 
be triggered in the steady state of the system, i.e. whenever 
the system is in mode Mg. In the case of mixed-criticality 
systems however, a mode change request IMCR^-|_2 could 
happen during the handling of the mode change request 
IMCR^+i. Indeed, in mode Alg, it is assumed no task Ti will 
generate a job the execution time of which will exceed Ci{£). 
If this nevertheless happens, then IMCR^+i is triggered, but 
this does not prevent the job of to keep on executing, 
potentially leading to exceed Ci(£+l) and trigger IMCRf+2 
while still handUng IMCR^+i. 
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III. The Protocol 

A. Introductory Definitions 

The OPA procedure described in Section II-C considers 
specific scenarios for each tasks of the system, where the 
execution time of each job ^ is exactly equal to the WCET 
of task Ti at a given criticality level £ such that I < £ < Li. 
These scenarios are called basic, as formalized by the follow- 
ing definitions. 

Definition 20 (Basic task scenario). At any time t, we call 
the scenario s* of task basic if for all c^ fc G s,*, there exists 
a criticality level £k G such that c^ fc = Ci{£k)- 

In a basic task scenario, each job released by a task will 
thus complete its execution after having consumed exactly its 
WCET at a given criticality level (which is not necessarily 
equal to the task's own criticality level Li). 
Definition 21 (Basic task set scenario). At any time t, we call 
the scenario of the mixed-critic ality task set t basic if every 
s* e s* is a basic task scenario. 

Definition 22 (Basically 5-Schedulable). Let 5 be a schedul- 
ing policy, and r a mixed-critic ality task set. We say t is 
basically 5-schedulable if, for any basic scenario of r, S 
generates a feasible schedule. 

Tlieorem 1 (Baruah et al. [13]). A mixed-criticality task set 
T is MC-schedulable on a given platform vr if r is basically 
5-schedulable by a given scheduling policy S. 

The OPA procedure thus aims at determining whether 
a given mixed-criticality task set r is basically MSM- 
schedulable. Indeed, during the WCRT computation at crit- 
icality level £, y£ e [^^L], the procedure considers each 
task Ti will release jobs whose execution times will be equal 
to Tj's WCET a some criticality level. The scenarios that 
are considered are thus basic. Consequently, if the OPA 
procedure succeeds, r is deemed basically MSM-schedulable, 
and according to Theorem 1, r is also MC-schedulable. 
Throughout this section, we will consider that the priority of 
a task is given by its index, such that task has a higher 
priority than task r^+i. 

B. Handling Increasing Mode Change Requests 

The offline analysis stage, whose goal is to vouch for the 
feasibility of the considered mixed-criticality system, intro- 
duces two sources of pessimism: 

• The WCET estimation introduces a level of pessimism 
which is as significant as the criticality of the considered 
task is high; 

• The WCRT computation, as it is carried out in Sec- 
tion II-Cl, leads to defining an upper-hound on the 
WCRT of each task, rather than the actual exact WCRT. 

The introduction of these sources of pessimism leads to over- 
estimate the actual requirements of the system. In particular, 
this means that during the execution of the system, a lot of 
computation resources could be wasted. In this section, we 
will show how to take advantage of the pessimism introduced 
during both the WCET and WCRT analysis stages by reclaim- 
ing these wasted resources, to allow the less critical tasks to 



complete their execution during the online scheduling phase. 
Before diving in the details of our contributions, recall that 
the WCRT computation assumes that whenever the system 
switches from operating mode Mg to operating mode 
at time iiMCRf+i^ each task Ti G t such that L,; < £, do not 
interfere anymore on tasks tj e r, such that Lj > £, from time 
^iMCRf+i onward. To prevent this interference when switching 
from operating mode Alg to operating mode Mg+i, the mixed- 
criticality system model prescribes the immediate suspension 
of each task satisfying Li < £, their potential rem-jobs being 
instantaneously dropped as soon as the mode change request 
IMCRf+i is triggered. As a result, if the main goal is to avoid 
jeopardizing the timeliness of the tasks the criticality of which 
is at least equal to ^ + 1, the completion of the rem-jobs must 
be handled in such a way that no interference can occur on a 
task with a criticality at least equal to ^ + 1. We now present 
our contributions, by suggesting three alternative approaches 
to avoid this interference. 

1) A Naive Approach: 

Upon an IMCR^+i, an intuitive approach consists in assigning 
the rem-jobs the criticality of which is less than £+1 a priority 
that is lower than the jobs the criticality of which is at least 
equal to ^ + 1. The execution of the rem-jobs thus takes place 
whenever there are less than m available jobs released by tasks 
Tj e T^+^. The following theorem proves this approach to 
be correct, i.e. (£ + l)-periodicity and (£ + l)-feasibility is 
preserved among an IMCRf+i. 

Tlieorem 2. Upon an IMCR^+i, assigning the rem-jobs of 
criticality level £ a priority that is lower than every task 
such that Li > £ + 1 is a valid increasing transition protocol. 

Proof: By assigning the rem-jobs a priority that is lower 
than every task Ti such that Li > £ + 1, they cannot interfere 
on the tasks r, G r^+^. It follows that the {£ + 1) -periodicity 
and {£ + l)-feasibility are preserved, and that this increasing 
transition protocol is valid. ■ 

2) A WCET-Based Approach: 

The drawback of the naive approach lies in the fact that 
upon an IMCR^+i, the completion of the rem-jobs having a 
criticality equal to £ can only occur whenever there are strictly 
less than m available jobs of criticality at least equal to £+1. 
As a consequence, the rem-jobs could complete their execution 
well beyond their deadline. We can however take advantage 
of the pessimism introduced during the WCET analysis to 
allow the rem-jobs to complete their execution earlier Indeed, 
recall that the offline analysis vouched for the feasibility of any 
basic scenario of the system. More precisely, and considering 
that the system is currently executing in operating mode 
Mg, this means that the scheduler will make the assumption 
that every job J, will complete its execution after exactly 
Ci.k = Ci{£) time units. Nevertheless, the fact is that & could 
complete its execution after an amount of time Ci,k such that 
Ci.k < Ci{£), in any scenario of criticality £. Let us therefore 

denote by uri.fc(£) '= Ci{£) — Ci,k the unused resources of J^ fe 
in any scenario of criticality level £. The value ur^ ^(f) thus 
represents a fraction of the resources that were reserved by 
the scheduler for job fe, under the assumption of a basic 
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scenario of criticality I, and that ^ did not consume. 
Following from the above discussion, we propose an alter- 
native increasing transition protocol, that slightly adapts the 
MSM scheduler during the transition phase. Indeed, the latter 
would act as if J; ^ did not complete its execution after Ci^fe 
time units, and take advantage of the unused resources to carry 
on the execution of the rem-jobs during exactly ur^ ^(i?) time 
units. Upon an IMCR^+i, recovering these unused resources to 
carry on the execution of the rem-jobs of criticality equal to i 
will preserve both the (£+l)-periodicity and (£+l)-feasibility, 
as proved by the following theorem. 

Theorem 3. Upon an IMCR^+i, the protocol that reclaims the 
unused resources uri.fc(i?+l) of every job J^ fe of criticality at 
least equal to £+1, to complete the execution of the rem-jobs 
of criticality £, is a vahd increasing transition protocol. 

Proof: The proof relies on the observation that reclaim- 
ing exactly ur^ ^(^ + 1) units of computation from task 
consists in simulating a basic task scenario for r^. Indeed, 
Ci_fc + urijt(£ + 1) = Ci{(. + 1). Since the system was 
deemed MSM-schedulable, it follows that any basic scenario is 
feasible. As a consequence, the proposed increasing transition 
protocol is valid. ■ 

3) A WCRT-Based Approach: 
As explained in Section II-Cl, an upper-bound on the WCRT 
Ri {£) of task Ti E T at criticality level £ is computed assuming 
an upper-bound on the interference suffered by Tj in the most 
pessimistic scenario of criticality level £. Furthermore, in the 
most pessimistic scenario of criticality level £, the job ^ 
should execute for exactly Ci{£) which is also an upper- 
bound on the execution time of task r^. Due to this twofold 
source of pessimism, it is consequently most unlikely that a 
job Ji^k released by task will ever complete its execution 
exactly Ri{£) time units after j.. However, the system having 
been deemed MSM-schedulable, it follows that the timeliness 
of each of its tasks could be respected in presence of this 
pessimism. In this section, we will thus suggest an increasing 
transition protocol which will enable for the reclaiming of 
unused resources, this time being based on the WCRT of each 
task. Our approach is based on the fact that the offline analysis 
assumed that a job Jj ^ could complete its execution Ri{£) 
time units after r^jt in any scenario of criticality level £. If, 
however, J^ fc completes its execution earlier, the scheduler 
will simulate the availability of j. until time rj + Ri{£), 
by assigning a processor to the rem-jobs whenever Jj would 
have been executed. The challenge of this section is to prove 
that this will not increase the WCRT of tasks having a lower 
priority. The following theorem formally proves that if every 
job released by tasks tj E hp(Tj) completes its execution no 
later than Rj{£) time units after its release, then every job 
released by task t; will complete its execution no later than 
Ri{£) time units after its release as well, in any scenario of 
criticality level £. 

Theorem 4. Each job J^ fc released by a task will complete 
its execution no later than Ri{£) time units after its release 
in any scenario of criticality level £< Li, if for every task 
Tj e hp(Ti), every job released by a task tj completes its 



execution no later than Rj{£) time units after its release. 

Proof: The proof is by induction on the priorities of the 
tasks. We will indeed show that if the property holds for every 
task up to Ti_i, then it must also hold for task t;. 
Base case: The base case consists in considering task ti, 
i.e. the task having the highest priority. Since ri suffers no 
interference at all, it is trivial that every job released by ti 
will complete its execution no later than Ri {£) — Ci {£) time 
units after its release, in any scenario of criticality level £. 
Induction step: Assume that the property holds for every task 
up to Ti_i and let us show that it must also hold for r^, by 
considering the execution of any job Jj ^ released by over an 
interval of length A. We will distinguish between two cases: 
Case 1: let us first consider that there are no more than m — 2 
carry-in tasks belonging to hp(i— 1) over the interval of length 
A. From Equation 1, according to the inductive hypothesis 
and since there are at most m — 2 carry-in tasks belonging 
to hp(ri_i), the actual total interfering workload suffered by 
task Ti_i over the interval of length A can be expressed as 
follows: 

Tjehp(ri_i) 

+ (3) 

TjGhp,„_2(Ti-l) 

Because carry-in tasks have a higher interfering workload than 
non-carry-in tasks, an upper-bound on the interfering workload 
cause by task Ti_i on task over the interval of length A is 
given by the following equation: 

lUA^,£) < if i,(A,^) + r,lZ{A,£) (4) 

Since the total interfering workload suffered by is equal to 
the total interfering workload suffered by Ti_i, plus the inter- 
fering workload suffered by from Ti_i, using Equations 3 
and 4, the actual total interfering workload suffered by job 
Ji,k over the interval of length A can be upper-bounded as 
follows: 

lU^J) < i*-i(A,£) + if^ti(A,£) + (5) 
However: 

i--(A,^)+ 

< J2 ^Ti^J) (6) 
Using Equation 1, we are able to conclude that: 

i*(A,^)< J2 ^"'(^'^) 

Tj<£hp{Ti) 

Equation 7 proves that the actual total interfering workload 
suffered by J; ^ will not exceed ii{A,£), thus implying that 
Ji.fc will complete its execution no later than Ri{£) time units 
after fc. 
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Case 2: let us now consider the case where there are at least 
TO— 1 carry-in tasks belonging to hp(i — 1) over the interval of 
length A. From Property 1, since the total interfering workload 
is upper-bounded when considering at most to — 1 carry-in 
tasks, Ti_i can be considered as a non carry-in task. An upper- 
bound on the interfering workload suffered by fc from task 
Ti_i is thus given by: 

i,_m(A,£)< ifi^,(A,^) 

As a consequence, the actual total interfering workload suf- 
fered by job Ji fc over the interval of length A, can be 
expressed as: 

i:(A,£)<i*_i(A,£) + lf\,(A,^) (8) 

According to the inductive hypothesis, we have: 

rjehp(ri) 

+ E i,T(A,^) (9) 

'rj6hp„,_i(ri_i) 

However, since hp(ri_i) C hp(Ti), we have: 

E i-r(A,^)< E i.-r(A,^) (10) 

Tjehp„_i(ri_i) Tjehp„,_i(r.i) 

By injecting Equation 10 into Equation 9, and by using 
Equation 1 we get the following upper-bound on the actual 
total interfering workload suffered by fe: 

i:(A,^)< E 

Tjehp(Ti) 

+ E i,-rw = ^^(A,^) (11) 

TjGhp,„_i(ri) 

Equation III-B3 proves that the actual total interfering work- 
load suffered by Ji^k will not exceed ii{A,£), implying that 
Ji.fe will complete its execution after no more than Ri{£) time 
units. ■ 
Corollary 1. Each job J^ jt released by a task will complete 
its execution no later than Ri{i) time units after Vi^k in any 
scenario of criticality level £ < Li, if every job Jj.p released 
by a task t, e hp(Ti) completes its execution exactly Rj{£) 
time units after Vj p. 

From Corollary 1, we propose an alternative increasing 
transition protocol, that slightly adapts the MSM scheduler 
during the transition phase resulting from the triggering of 
IMCR^+i. Upon the completion of a job ^ released by a 
task Ti such that Li > £ + 1 at time fij^ < Ti ^ + Ri{£ + 1), 
the scheduler would simulate the availability of ^ in the 
interval [fi^k,ri^k + Ri{£ + 1)], thus acting as if Ji^k had 
suffered an interference equal to the upper-bound lf{Ri{£)), 
and had completed its execution exactly at time ,fc + Ri{£). 
The following theorem proves that this approach will preserve 
both the (£ + l)-periodicity and {£ + l)-feasibility. 
Theorem 5. Upon an IMCR^+i, the protocol that simulates 
the availability of each job ^ such that Ji > £+1 until time 
ri,k + Ri{£ + 1), to complete the execution of the rem-jobs of 



criticality £, is a valid increasing transition protocol. 

Proof: This is an immediate consequence of Theorem 4. 
Indeed, by simulating the availability of each job Ji k released 
by task until time ri^k + Ri{£ + 1), we simulate the 
upper-bound on the interference suffered by Ji^k- According 
to Corollary 1, this will not increase the WCRT of tasks 
Tj € Ip(ri). As a consequence, the proposed increasing 
transition protocol is valid. ■ 

4) Conclusion and Discussion: 
In this section, we have proposed several approaches to handle 
the transition from criticality level £ to criticality level £ + 1. 
The proposed approaches have a common goal, as they all 
allow to reach a compromise between a high safety, which 
is implied by the high level of pessimism adopted during the 
offline analysis phase, and an efficient usage of the platform, 
by recovering the unused resources to execute the less critical 
tasks during the online phase. In our opinion, this is an 
important aspect of our work, as it highlights the crucial fact 
that a high level of assurance does not necessarily imply that 
resources are doomed to be wasted. 

Finally, note that the proposed approaches do not assume 
anything on the execution order of the rem-jobs. We will thus 
briefly discuss what management policy can be implemented 
in the case the system switches from operating mode Mi to 
operating mode at time iiMCR^+i while some rem-jobs 

of criticality equal to ^ — 1 are still available. This means that 
at time tiMCR^+i, the system has to complete the execution of 
rem-jobs the criticality of which is less than £. In that case, 
either it is assumed that since their criticality is less than the 
current criticality of the system, they are all equal in terms 
of importance, meaning that a global strategy can be applied 
to complete their execution (complete the rem-jobs with the 
shortest deadline first, complete the rem-jobs with the shortest 
remaining processing time first, etc.). Or we can assume that 
even though the current criticality of the system is higher than 
their own criticality, the relative importance of the rem-jobs 
remains the same, meaning it is safer to complete the rem- 
jobs in decreasing order of criticality level (the rem-jobs with 
a criticality equal to £ have to be completed before the rem- 
jobs with a criticality equal to ^ — 1). 

C. Handling Decreasing Mode Change Requests 

In our previous work [8], we focused on wniprocessor 
platforms, and proved that whenever an idle time was 
detected, while the system had reached criticality level 
£ > 1, it was safe to re-enable every task that had previously 
been suspended. However, the occurrence of a simultaneous 
idle time on every processors of a multiprocessor platform 
is unlikely. In this section, we will therefore suggest an 
alternative approach to re-enable the suspended tasks without 
relying on the occurrence of idle times. Before going any 
further, let us introduce the following property, which 
highlights two important requirements regarding task re- 
enablement. 

Property 2. When the system is switching from operating 
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DMCR, 



Jobs whose execution is still influenced by the 
total interfering workload at criticaiity level h>i 
Jobs whose execution is not influenced anymore by 
the total interfering workload at criticaiity level h > ( 



Figure 1. The decreasing mode transition protocol iteratively identifies the 
time instants ^ < Ri{(.) for every task £ r'*. 

mode Mh to operating mode upon a DMCR^ at time ^dmcrj, 
the re-enablement of a previously suspended task t; belonging 
to Mi at time t > t^MCRe carried out provided that the 

following two conditions hold: 

• The re-enablement at time t of task must not jeopardize 
the /i-periodicity and /i-feasibility of the system; 

• Task Ti must be guaranteed to meet its deadline from time 
t onward if no IMCR^+i occurs at a time tiMCRf+i ^ ^■ 

In the rest of this paper, we will say that it is safe to re- 
enable a task Ti if Property 2 holds upon the re-enablement of 
Ti. The way new-mode tasks are re -enabled leads to distinguish 
two types of protocols. 

Definition 23 (Synchronous/Asynchronous protocol [1]). As- 
suming the system is switching from operating mode Mh to 
operating mode Mi, a synchronous protocol is a protocol that 
re-enables each suspended task belonging to operating mode 
simultaneously. An asynchronous protocol is a protocol 
that enables every suspended task belonging to operating mode 
Ml independently from the others, i.e. some tasks belonging 
to Mg might be enabled earlier than others. 

Assuming the system is executing in operating mode Mh, 
and depending on the set of functionalities the system is 
willing to re-enable, once the rem-jobs of criticaiity less than 
h are completed, a DMCR^, 1 < £ < h can be triggered. 
For the sake of clarity, we will assume that no IMCR£+i is 
triggered during the decreasing mode change (we will shortly 
discuss this potential event later). We suggest a synchronous 
protocol, illustrated by Figure I, that works as follows: starting 
at time tuMCRf the protocol identifies the first job Jh^.k 
released by task Th^ that completes its execution at time 
fhi,k < rhi,k + RhA^)- From time fh,,k, the protocol then 
identifies the first job Jh2,p released by task Th^ that completes 
its execution at time fh2.p < ''/i2-p + Rh2{^)- Th^ procedure 
then keeps on identifying one such job for each task Ti e t'\ 
in order of their priority (i.e. it identifies such a job for task 
Th- only when it has previously identified such a job for task 
T/ii.i)- The re-enablement of the previously suspended tasks 
having a criticaiity at least equal to I can then take place 
when the procedure identifies a job J„^,s that completes its 



execution at time fnh,s < fnh,s + Rnni^)- the following, 
we will assume that if the protocol identifies a job Jhi,k that 
completes its execution at time fhi.k < rh-.k + Rii^), then this 
means that the procedure has already identified such a job for 
every tasks Thi,Th2, ■■■,Th,_^,- 

Lemma 1. Whenever a task Th^ € r'* releases a job Jhi.k that 
completes its execution at time fhi.k < ^h^.k + Rhi{i), and 
no IMCR£_|_i is triggered during the mode change, then the 
actual interfering workload suffered by tasks Tj E lp(T;i.) 
from task Thi, from time fhi,k onward will be less than or 
equal to ih]j{A,£) (resp. 1^. j{A,£)) over any window of 
length A, if r/j. is a carry-in (resp. non carry-in) task for tj. 

Proof: The upper-bound on the interfering workload 
suffered by task tj E 1p(t/i. ) from task Th- over an interval 
of length A, in any ^-interval, is computed assuming Th^ 
will release jobs that will execute for no more than Chi{£) 
time units. However, if no IMCR^+i is triggered, then it 
must be the case that every job released by task Th^ executes 
for no more than Chii^) time units. Therefore, from fh^.k 
onward, the actual total interfering workload suffered by tasks 
Tj E Ip (t/iJ from task r^. will be less than or equal to 
il^.j{A,i) (resp. if: ,i{A,e)) over any window of length A 
if Thi is a carry-in (resp. non carry-in) task for tj. ■ 
Lemma 2. Let us assume the protocol identified a job Jhi_i,k 
that completed its execution at time fhi_i,k < 'rhi_^,k + 
Rhi-i {(-)■ From time fhi^i.k onward the actual total interfering 
workload I*(A,^) suffered by task Th^ over any window of 
size A will be less than or equal to Ii(A,£). 

Proof From Lemma 1, we know that from time fhi^i.k 
onward, the actual interfering workload of every task Tj E 
hp(T/i.) on Ti is less than or equal to I^^Jj. (A,£) or 
I^'^j^ (A, f), depending whether Tj is a carry-in task for t/;. or 
not. Furthermore, from Equation 1, we know that an upper- 
bound on the total interfering workload suffered by task t/,; 
is given by summing I^"^. (A,^) Vtj E hp(r/j.) with the 
TO — 1 largest values of I°"5f/(A,^). Thus, the actual total 
interfering workload suffered by Th^ will be less than or equal 
lolhA^J). ' ■ 

Corollary 2. Upon a DMCR^, when the protocol identifies 
a job Jnh,s that completed its execution at time fnh,s < 
fnh,s + Rnhi^)' then from time onward, the actual total 
interfering workload suffered by any task € r is less than 
or equal to Ii(A, £). 

From Corollary 2, we will now show that it is safe to re- 
enable every suspended task E at time 
Lemma 3. Upon a DMCR^, when protocol identifies a job 
Juf^.s that completed its execution at time fn^.s < fuh.s + 
Rn^ {£), then the jobs released by every suspended task t^ E 
T^ from time fn^,s onward will meet their deadlines in any 
scenario of criticaiity level at most Lk- 

Proof The WCRT at criticaiity level £ of each task Tk E 
T^ was computed assuming a total interfering workload of 
ii{A,£). But from Corollary 2, we know that at time fn,i,s, 
the actual total interfering workload suffered by any task r, in 
the system is less than or equal to li{A,£). Since the system 
was deemed MSM-schedulable, every job released by a task 
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Tk E T from time fn^.s onward will meet its deadline in any 
scenario of criticality level at most Lk- ■ 
Lemma 4. Assume the system is executing in operating mode 
Mfi- Upon a DMCR^, when protocol identifies a job Jnh,s 
that completed its execution at time fn,^.s < '^n^.s + Ruhi^), 
the re-enablement of every suspended task € will not 
jeopardize the /i-periodicity and /i-feasibility. 

Proof: From Corollary 2, we know that at time /„^^s^ 
the actual total interfering workload suffered by any task 
in the system is less than or equal to Ii(A,£). However, this 
upper-bound is computed assuming that every task g 
will release jobs that complete their execution after no more 
than Ci{t) time units. Therefore, the actual total interfering 
workload suffered by any task Tj upon the re-enablement of 
every suspended task Tk G will still be less than or equal to 
Ii(A,^). Furthermore, since the system was deemed MSM- 
schedulable, it follows that every job released by tasks Tj e 
will meet its deadline in any scenario of criticality up to level 
Lj > h. It follows that both the /i-periodicity and /i-feasibility 
are preserved upon the re-enablement of every suspended task 

Tk e t'. ■ 

Theorem 6. Let us assume the system is executing in operat- 
ing mode Mh- Upon a DMCR^, when the protocol identifies 
a job Jnh,s that completed its execution at time fnh,s < 
fnh,s + Ruhi^), it is safe to re-enable the suspended task 
belonging to the operating mode Mi at time fnh,k- 

Proof: To prove this theorem, we have to show that Prop- 
erty 2 holds upon the re-enablement of every suspended task 
Tj G at time fnh,k- Lemma 3 proved that every suspended 
task Ti belonging to the operating mode could release jobs 
that would be able to meet their deadline if Ti was re-enabled 
at time fn,^.k, and provided that no IMCR^+i was triggered. 
Furthermore, Lemma 4 proved that the re-enablement of every 
suspended task ti belonging to the operating mode Mi would 
not jeopardize the /i-periodicity and /i-feasibility. It follows 
that at time /„,^.fc, it is safe to re-enable every suspended task 
belonging to the operating mode Mi. ■ 
Theorem 6 proves that it will eventually be possible to 
decrease the criticality level of the system, provided the 
computational demand of the tasks having a criticality higher 
than or equal to h decreases. It follows that the suspension 
delay suffered by tasks having a criticality less than h is re- 
duced. In practice however, if an IMCR^+i is triggered during 
during the DMCR^ handling, then the procedure that consists in 
finding the first job Jnh,s that completes its execution a time 
fnh,s < ^nh,s + ^?nh(^) IS aborted. Indeed, in that case, we can 
no longer guarantee that the additional interfering workload 
generated by tasks having a criticality equal to £ will not 
jeopardize the {£ + 1) -periodicity and {£ + 1) -feasibility. 
Corollary 3. Upon a DMCR^, reenabling every suspended task 
belonging to operating mode M( upon the identification of a 
job Jn^.s that completed its execution at time fn^,s < + 
Ruh W is a valid decreasing transition protocol. 



IV. Conclusion 

In this work, the first contribution consisted in formalizing 
mixed-criticality systems in terms of multi-moded systems, 
thus giving a new outlook to the problem. As a second 
contribution, we have shown that multi-moded approaches 
could help solve the consistency problems that arise when 
less critical tasks are brutally discarded, by enabling for 
a softer switch from a lower criticality level to a higher 
one. Finally, as a third contribution, we have highlighted 
the fact that the behavior of such systems could be greatly 
enhanced, by proving that task re-enablement was possible 
without compromising its safety. Those approaches allow to 
achieve a much more adept usage of the platform, by avoiding 
to vainly waste computational resources. Future work will 
concentrate, among other things, on suggesting asynchronous 
decreasing transition protocols, which allow for a progressive 
re-enablement of the less critical tasks. 
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